fix(plugin-detail): copy object-valued cells as JSON, not [object Object] - #8460

Fixes #8395

DetailSection's click-to-copy built its payload with String(value), and String() of an object is the literal text [object Object]. The affordance is offered for every non-empty value — objects included (canCopy is hasCellValue, objectui#8376) — so a reader clicking the copy button, the row, or pressing Enter on an address, geolocation, JSON, file, expanded-lookup, repeater or image cell silently got a placeholder on the clipboard while the cell beside the button rendered that same value correctly. Nothing errors; it is noticed only on paste.

The change is one read site: objects are serialized with JSON.stringify, everything else keeps String().

Per-kind payloads — measured, not reasoned

Rendered via a real DetailSection at innerWidth 1280; the observed value is the ARGUMENT handed to navigator.clipboard.writeText.

⚠️ One payload moves without having been broken — the multiselect. An array IS an object, so ['alpha','beta'] now copies as a JSON array. The new form is lossless where the old one was ambiguous for any value containing a comma. It is called out here rather than buried: it is the only row whose BEFORE column was not already a placeholder.

⭐ The non-regression half

Every correct-today scalar payload is byte-identical, and the pin asserts the rendered text beside it, so it is red for any later "just copy what the cell renders" rewrite:

What this deliberately does NOT decide

• ⚠️ The JSON blob is a defensible default, not a settled contract. The read site now says so in place, naming objectui#8395's option B — a shared value-to-text formatter reusing the cell renderers' own formatters (formatAddress, objectui#4037) — as where the real per-kind contract gets decided. That needs product answers that do not exist yet (address under which locale, geolocation at stored precision or displayed rounding, json compact or pretty, file filename or list or URL, multiselect labels or values, lookup name or id, image URL or filename) and is a separate card.
• ⛔ Copying the rendered text (option A) was measured and rejected. It is the worse contract for 9 of 17 field types and loses data silently: date renders Mar 4 (the year is gone), percent renders 12% against a stored 0.123 (a different quantity), datetime concatenates to an unparseable 3/4/20265:06 am, image and boolean render no text at all — so those two would copy the EMPTY STRING, an implementation strictly worse than the defect. It would also make the payload display-locale dependent.
• ⛔ Withdrawing the affordance from text-less cells (option D) stays out: it would narrow canCopy away from hasCellValue, whose three readers must agree per objectui#8376's docblock.
• ⛔ objectui#8440 is not addressed here and its code path is byte-for-byte untouched: the password / secret branch of this same handler (copy writes the raw secret while the cell renders the mask) is in the maintainer's decision box. The pin asserts nothing about it on purpose, so whichever way that card is answered, no case in this file turns red. That card remains open.

The one addition beyond the literal one-liner

JSON.stringify throws on a cycle, and this runs inside a click handler. The stringify is therefore wrapped in the SAME try / catch that JsonCellRenderer already applies to this exact operation on this exact value, falling back to today's string form. It is pinned (a self-referencing value still copies [object Object] and the click does not throw) and is the only input for which that text is still written. Strike it if you would rather have the bare call.

Ablation — proof the pin can fail

Run from the committed implementation, restoring the copy handler's bare String(value). ⚠️ There is a SECOND String(value) in this file — displayValue's no-renderer fallback — which is NOT this defect; the mutation is anchored on the handler body and that second site is asserted unmoved.

HEAD blob            014ec9dc9f356d7c2f0267c5c4f1389cfca70324
on disk, mutated     6f5bde22876b224f753718e4a028eb41a9d932c3   ⇒ the mutation reached disk
anchors  JSON.stringify(value)                1 -> 0
         bare one-liner (copy handler)        0 -> 1
         '      return String(value);' (L420) 1 -> 1   (the OTHER site, unmoved)
result   Tests 9 failed | 8 passed (17)
restore  on-disk hash == HEAD blob AND `git diff HEAD` empty   ⇒ restored BY STATE, not by an exit code

The nine red rows, by name — every one an object-valued kind, each failing on its payload (Received: "[object Object]") while its rendered-value CONTROL still passed, so the failure is about what was copied and never about a blank cell:

OBJECT — 'Billing Address' / 'Office Location' / 'Payload' / 'Contract' /
         'Owner' / 'Attachments' / 'Line Items' copies parseable JSON …
OBJECT — an image cell copies its JSON even though it renders no text
OBJECT — a multiselect copies its stored values as a JSON array

The eight that stayed green under the mutation are exactly the ones that must: the six scalars, the boolean, and the unserializable-value case.

Verification

No downstream package asserts this payload: of the nine test files in the repo that touch clipboard, the only two that render this surface are in packages/plugin-detail.

Changeset

minor, on @object-ui/plugin-detail — this moves a shipped clipboard payload, which is user-visible behaviour; the landed precedent for a record:details behaviour change is PR #8396. The repo forbids major. Gate verdicts, quoted:

✅  2 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s): .changeset/8395-detail-copy-object-values.md.
✅  No changeset declares a `major` bump.

Generated by Claude Code